Secure fetch of digital content

ABSTRACT

A Secure Fetch feature can be included with any file sharing or transfer service that allows access to files, folders and digital content where the party that is to gain access or possession of the materials (the requestor) desires to utilize an application that facilitates access or transfer of the materials and the party in possession of the materials (the requestee) is not required to log in to an application or even to download or open it.

BACKGROUND OF THE INVENTION 1. Field of the Invention

This invention relates to allowing access to files, folders and digitalcontent where a party that requests access or possession of thematerials (the requestor) desires to utilize an application thatfacilitates access or transfer of the materials and the party inpossession of the materials (the requestee) is not required to log in toan application or even to download or open it. In particular, thisinvention relates to allowing a requestor to initiate allowance ofaccess or transfer of materials using an application of the requestor'schoice that offers the security, privacy, or other features desiredwithout requiring the requestee to download, log in to, or have anaccount associated with the application.

2. Related Art

Existing file transfer and sharing mechanisms typically require users tosubscribe to a service, to install special file transfer software, orboth. While some services allow for the sharing or transfer of files toan individual without an account that has not installed specialsoftware, those services still require the individual that is inpossession of the files to be shared or transferred to have an accountwith the service. “Secure Fetch” enables individuals outside of the filesharing system to transfer and share files and folders to users insidethe file sharing system, without the need for an outside individual toinstall special software, join a server, or to otherwise sign up for afile sharing service.

Secure Fetch is intended to be used with any public cloud or digitalcontent or file sharing application. In one preferred embodiment, theSecure Fetch capability is specifically configured to be used with thePervasive Intermediate NAS Application (PINApp) set forth in U.S. Pat.No. 9,792,452, which is hereby incorporated by reference as if fully setforth herein, and may also be utilized with the PINApp AsynchronouslyRendered Conduit (ARC) feature set forth in U.S. Pat. No. 10,708,273,which is also hereby incorporated by reference as if fully set forthherein.

PINApp is an efficient, cost effective and simple way for users to storeand share their digital content using public cloud services, without therequirement to upload their digital content to the public cloud, andwithout the requirement to purchase an expensive “Network AttachedStorage” (NAS) or “Personal Cloud Device” (PCD). Further, the PINAppnegates the need for expensive cloud storage service subscription plansbecause digital content is stored on the user owned/managed device andnot on the public cloud.

PINApp creates a digital environment wherein a user can store theirdigital content on a device they own (computer, smartphone, tablet,etc.) and both access and share that digital content through a publiccloud service without the need to upload the digital content to thecloud.

PINApp ARC allows digital content to be accessed by connected devices(via PINApp) and also to be accessed by non-connected devices residingoutside the PINApp system, using a profile managed by the owner of thecontent that allows the owner to maintain control over it.

SUMMARY OF THE INVENTION

Current known in the art file sharing and transfer systems require auser wishing to transfer or share a file, folder or other digitalcontent to sign up for a service and install special file sharing ortransfer software to enable the transfer or sharing of files, foldersand other digital content that is commonly managed through computer anddigital content storage systems. While these systems perform the relatedfunctions, the requirement to subscribe to, or otherwise join a serviceis undesirable for some parties.

There remains a need for a user to have the capability of obtainingcontent from a second person who may not be registered as a user of thesystem in a secure manner. That is, it may be that an individual isvigilant about where they store their own files and how they share themwith others. For example, instead of using a public cloud for filestorage and sharing, an individual may utilize a method that meets theirsecurity needs to do so. For example, a user may utilize PINApp, whichallows for files to be shared without a requirement that they ever beuploaded to or stored on a public cloud, and is thus more secure thanother competing file sharing or transfer services. However, even if anindividual routinely uses secure methods to transfer files, when thesame individual desires to receive files from another, the individualmay depend on the other person's file sharing or transfer methods, whichmay not have the desired security or may be lacking in some othermanner.

If a user desires to obtain digital content from another individual, andthe user desires to maintain a high level of privacy for that digitalcontent, the user is often limited to the desire and capability of theother individual to maintain the same level of privacy. For example, theinformation being transmitted may be more valuable to the user than tothe individual, or the individual may not be a person that issophisticated enough with technology to understand the risk associatedwith transmitting private information. Or, the user may be legally orotherwise responsible for the privacy and security of the individual'sprivate information. In present systems, ensuring an acceptable level ofprivacy may require the individual to sign up for an account with aservice that will facilitate it, an extra step that the individual maynot be motivated enough to or easily capable of doing.

In instances such as in the legal and medical professions, it is oftenthe case that clients and patients are requested to provide privateinformation in written form that often ends up being supplied to therequesting business through means such as email attachments, or byinstalling a file transfer application on their computing device. Inother instances, clients or patients may be requested to sendinformation via a common file sharing application that has less thandesirable security. Thus, while such methods perform the requiredfunction of transferring a file, folder or other digital content to thesubject requester of the file, they are often lacking in security (suchas an email attachment) or require the person submitting the file toinstall additional software or take other steps to provide the necessaryfile to the requester.

Therefore, a need exists to facilitate a file, folder and/or digitalcontent transfer capability that negates the need for the obligatedparty (the party providing the requested content) to take extra steps inorder to provide the requested digital content.

The devices, features, and functions described herein are intended todisclose a system and method to allow the transfer of digital contentsuch as a file, folder or other media from a file owner to one or morerecipients without the need for the file owner to install specialsoftware, join a transfer service or use email attachments in order tofacilitate the requested file transfer.

The present invention addresses the need for a user to easily obtaindigital content from an individual in a manner such that the user willensure privacy and security of the digital content and the individualwill need to take as little action as possible, even if the individualis not a user or does not have an account with the system that the userhas selected to facilitate the sharing of the digital content.

Secure Fetch is a system and method that enables a file requester suchas a business or enterprise to send a request (via email as an example)for a file to a non-affiliated party that enables that party to load therequested file to an embedded link contained in the email by eitherlaunching the link in a web browser or dragging and dropping therequested file directly into the link contained in the email.

Secure Fetch is particularly well suited to enable the transfer offiles, folders and digital content from non-affiliated parties tobusiness and enterprise interests such as medical, legal and otherrelated disciplines wherein digital content is shared by thenon-affiliated party to the respective business or enterprise. Byallowing clients of businesses such as medical and legal professionalsto share their digital content without the need to install, employ orotherwise utilize a file sharing or transfer service or application,Secure Fetch simplifies the process of file transfer for those that donot otherwise have a file transfer service. Further, by eliminating theneed to send an email attachment of sensitive or proprietary information(such as legal and medical records), Secure Fetch creates a temporaryand secure environment in which to transfer files from a non-affiliatedparty to a file requester.

In a preferred embodiment, Secure Fetch is a feature that is includedwith a secure file sharing and transfer application such as the PINApp.The PINApp, as it presently exists, enables a user of a computing device(personal computer, smartphone, tablet, etc.) to designate a digitalstorage repository (file, folder, USB stick or other connected internalor external drive) to connect to the public cloud for the purpose ofsharing their digital content. In one preferred embodiment, the PINAppmay be downloaded and installed on a personal computing device such as asmartphone or a tablet, and be used to allow the owner of the smartphoneor tablet to share their photos with another person. The PINApp negatesthe need for the user to email or otherwise transfer their photos to thecloud, and enables them to share the photos directly with friends andfamily from their device using existing cloud storage and sharingservices. By allowing users to share their digital content directly fromtheir device, the PINApp negates the need for users to purchaseexpensive Local Area Network (LAN) connected Personal Cloud Devices(PCDs) or to subscribe to expensive cloud services. The PINApp allowsthe user to utilize the storage space on their computing device (orotherwise connected to their device such as an external hard drive)instead of the cloud or PCD storage space, saving upload time and thecost associated with paying for online (cloud) storage space or NetworkAttached Storage (NAS) devices and other “personal cloud” type devices.This also allows the user to control the privacy and security of theuser's materials, rather than uploading them to storage space whereprivacy and security may be compromised, either by the terms of serviceof the space, or by virtue of the space being less secure than a devicethat the user controls.

The PINApp also allows a user to digitally assign (or pin) a folder thatis hosted on their computing device directly to the public cloud. This“pinned” folder enables the user to place digital content into thefolder to be accessed and shared directly through the public cloud,negating the need for a designated PCD or NAS device. The digitalcontent that is stored in the pinned folder can be shared with one ormore recipients through a publicly available cloud storage provider, butwill remain on the local device, ensuring both privacy and security ofthe digital content. By allowing the digital content to be storedlocally and not uploaded to the cloud, the PINApp bypasses expensivecloud storage service agreements because the PINApp negates the need toutilize the cloud service provider storage space. All of the digitalcontent is stored on the device of the user/owner initiating the PINApp.PINApp is more fully described in U.S. Pat. No. 9,792,452, which ishereby incorporated by reference as if fully set forth herein.

PINApp ARC, as it presently exists, allows digital content to beaccessed by connected devices (via PINApp) and also to be accessed bynon-connected devices residing outside the PINApp system, using aprofile managed by the owner of the content that allows the owner tomaintain control over it. PINApp ARC allows a digital content owner tocreate a profile that will determine the usage parameters that govern apiece of digital content such as a file, or a group of digital contentsuch as a folder or the contents of an entire server or drive. The ARCprofile contains information such as what file(s) are being managedthrough the ARC, what access rights are assigned to each individual useror groups of users, if the digital content usage will expire or lapseover time, and if the digital content may be moved from an original hostlocation to a secondary location, or even a third-party location. PINAppARC is more fully described in U.S. Pat. No. 10,708,273, which is alsohereby incorporated by reference as if fully set forth herein.

However, in the existing PINApp and PINApp ARC, content can only beprovided by a user of the system, which requires the user to have anaccount and to utilize PINApp software.

In a preferred embodiment of Secure Fetch, it is utilized with PINAppsuch that an individual can pin a folder with digital content that theindividual desires to share or transfer even though the individual doesnot have an account with PINApp, has not downloaded or installed any ofthe PINApp software, and has not downloaded any other file transfersoftware. This could be facilitated by an individual that does have aPINApp account who sends a link to the individual (who is not a PINAppuser) that allows that individual to pin their content, making itaccessible to others, such as the PINApp user that facilitated the pin.

In another preferred embodiment, Secure Fetch is utilized with PINAppARC, such that a profile for content that is to be accessed or sharedcan be created by a PINApp user, where the content itself that will besubject to the profile is able to be provided by an individual that isnot a PINApp user and has not downloaded PINApp software.

In a preferred embodiment, the system provides a Secure Fetch capabilitythat enables the ARC to be used to allow a non-affiliated party (aperson that is not a registered user of the system) to transfer orotherwise share files and/or folders using an ARC profile (in thecontext of Secure Fetch, an ARC profile may be more specificallyreferred to as a Secure Fetch profile) created by an affiliated party.More specifically, Secure Fetch enables an empty ARC (Secure Fetch)profile to be created by a user with system access (referred to hereinas a requestor) that can be sent to a non-affiliated party (referred toherein as a requestee), and populated with files, folders and otherdigital content before then being sent to an end recipient (asdesignated by the creator of the ARC profile, the requestor) of thecontent. The purpose of this is to expand the capabilities of the ARC toinclude use by persons outside the system, but with the need toprivately and securely share digital content with persons that areregistered to the system.

The ARC allows one or more profiles to be created by a requestor, who isan ARC user, and then sent to one or more requestees to add one or morefiles, folders or digital content. That is, the Secure Fetch profile iscreated for the purpose of enabling a requestor to send an empty SecureFetch profile to a requestee, allowing the requestee to populate theSecure Fetch profile with digital content such as files, folders,pictures, videos and the like. The completed Secure Fetch profile isthen returned to the requestor, and/or to one or more third parties thatare to be granted access to the digital content as designated by theuser creating the Secure Fetch profile (those granted access arereferred to herein as grantees). In some embodiments, each Secure Fetchprofile can contain one or more pieces of digital content (files,folders and the like) and can be destined for return to the requestor(who created the Secure Fetch profile), or one or more grantees asdesignated by the requestor (who created the Secure Fetch profile).Further, a single profile can be created and sent to multiple requestees(content owners) so that the content can be populated by the multiplerequestees (content owners), and then sent to the requestor who createdthe Secure Fetch profile, and/or to one or more grantees as designatedby the requestor (who created the Secure Fetch profile). In analternative embodiment, a requestee may also identify grantees.

From the discussion that follows, it will become apparent that thepresent invention addresses the deficiencies associated with the priorart while providing additional advantages and benefits not contemplatedor possible with prior art constructions.

Other systems, methods, features and advantages of the Secure Fetchcapability will be or will become apparent to one with skill in the artupon examination of the following figures and detailed description. Itis intended that all such additional systems, methods, features andadvantages be included within this description, be within the scope ofthe invention, and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The components in the figures are not necessarily to scale, emphasisinstead being placed upon illustrating the principles of the invention.In the figures, like reference numerals designate corresponding partsthroughout the different views.

FIG. 1 is a block diagram, depicting the general flow of the SecureFetch functionality;

FIG. 2 is an illustration depicting a user interface that may beprovided to a requestee when the Secure Fetch functionality is used; and

FIG. 3 is a flow diagram illustrating the creation of a Secure FetchProfile using Secure Fetch with the PINApp ARC.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The functional elements of the Secure Fetch system and method will nowbe discussed with reference to FIG. 1. Please note that while otherfunctional elements exist within the system, this disclosure focuses onthe primary and preferred embodiments of Secure Fetch. It would beobvious to one skilled in the art to alter or otherwise modify thedisclosed elements to change functional aspects of Secure Fetch. Pleasealso note that a party receiving a Secure Fetch share link to bepopulated with digital content is referred to in the discussion thatfollows as a “requestee.” This is the party who will be providing thedigital content being requested by a “requestor” via the Secure Fetchsystem and method.

As can be seen in FIG. 1, the Secure Fetch 105 is intended to bedeployed within a computing system that provides a processor 110, acommunication device 115 and additional host devices 120 that caninclude (but are not limited to) storage repositories such as localdrives, USB drives, internal and external storage drives, servers andother computing devices capable of storing digital content andcommunicating through networks with other computing devices.

Secure Fetch 105 provides an access authentication 125 function thatworks in conjunction with the host system to enable a requestor toaccess the Secure Fetch 105 system. Access authentication 125 mayinclude (but is not limited to) the use of a username and password,multifactor authentication and other known in the art access andauthentication methodologies. Once access to the Secure Fetch 105 systemthrough the access authentication 125 is complete, the requestor willenter the Secure Fetch operating system 130. The Secure Fetch operatingsystem 130 controls all functional elements of the Secure Fetch 105system. These functional elements include (but are not limited to) theinstructions input user interface 135 that provides a graphicalinterface (not pictured) to be used by the requestor (not pictured) tonavigate the functions and controls of the Secure Fetch 105 system; theantivirus and antimalware administration 140 function that governs theusage and application of antivirus and antimalware elements within thesystem; an authentication function 145 that enables therequestor/provisioner of the Secure Fetch 105 to apply, if desirable,requestee and/or grantee authentication methods such as username andpassword protection or a PIN, multifactor authentication and otherfunctional elements governing access to the system by a requestee or agrantee; a file and folder input management 150 function that governsthe use of content to be provided by a requestee (which may be onerequestee or multiple requestees); and a system communications 155function that administrates all communications from the Secure Fetch 105to the host system being managed by the processor 110. The systemcommunications 155 additionally provides notifications and messagingfrom other system sources such as memory allocation messages, error andconfirmation messages and the like; an IP gateway administration 160function that enables a requestor of the Secure Fetch 105 system toenable or disable receipt of digital content such as files and foldersfrom specific IP addresses; a requestee display management 165 functionthat governs the user interface for requestee devices such as acomputer, smart phone, tablet or other known in the art computingdevices; an encryption function 170 that allows a requestee to choose toencrypt the digital content (files, folders, etc.) they wish to share tothe user of the Secure Fetch 105 system; a database 175 that works inconjunction with the host system managed by processor 110 to storeinformation including (but not limited to) requestor and, wheredesirable, requestee and/or grantee login information, files and folderstransferred into and out of the Secure Fetch 105 system, device and IPaddressing and MAC code information and the like; a requestee messagingfunction 185 that enables a requestee to create and send messages to,for example, a requestor, through the Secure Fetch 105 system; and acalendar and expiration timer function that enables the requestee tomanage the timeframe that the digital content they are sharing throughthe Secure Fetch system 105 will be made available. The requestorprovisioning the Secure Fetch 105 system may choose to enable or disableany of the above functional elements contained within the Secure Fetch105 system, based on the needs of the requestor. While not specificallypictured, the system also allows the requestor to perform thesefunctions, including to send messages and to set an expiration timer.

As an example of functional elements of the Secure Fetch 105 systembeing enabled and disabled, Secure Fetch 105 may be deployed by ahospital or other medical provider. The requestee (a patient of thehospital in this example) of a Secure Fetch share link may be requiredto provide documentation from another medical provider to the subjecthospital. The Secure Fetch 105 requestor (the hospital) may disable thecalendar and expiration timer 190 to prevent the requestee (patient)from stopping the hospital from downloading or otherwise havingpermanent access to the documentation being requested from the requestee(patient). The system may be configured to allow a requestor to have anynumber of administrative functions to control the options that will bepresented to a requestee.

Secure Fetch is intended to provide a seamless method to enable arequestee to provide files, folders and other digital content (asrequired) to the Secure Fetch requestor, while negating the need for theSecure Fetch requestee to utilize email attachments, cloud storage, filetransfer apps or other extra steps that would otherwise be required toperform the transfer of digital content between computing devices,networks and realms.

With reference to FIG. 2, an example of the Secure Fetch from arequestee perspective will now be discussed. It is important to notethat while other embodiments exist, the discussion has been limited tohighlight the preferred embodiments and functional elements of theSecure Fetch function. Using the previous example, we will assume thehospital is the Secure Fetch requestor and the requestee is a patient ofthe subject hospital.

With reference to FIG. 2, the process begins by the hospital (requestor)sending a link 205 to a patient (requestee). This link can be providedthrough typical known in the art messaging applications such as email,text messaging, SMS messaging, chat programs and through digital contentsuch as word documents, PDF documents and other commonly transmittedmedia methods. The patient may open the link 205 using a typical webbrowser or other system software capable of enabling communications fromthe patient computing device to a remote computing device such as aserver, smart phone, laptop, tablet or other commonly known in the artsystems.

Once the patient opens the provided link 205, a menu window 210 willopen within the patient's computing device. As stated previously, thiscould be any commonly known device including a personal computer, smartphone, tablet or other. As can be seen in FIG. 2, the menu window allowsthe patient to add files by selecting the add files 215 option or bydragging and dropping 220 the files into the provided window. Selectingthe add files 215 option will open an additional window 225 on thepatient's computing device to allow them to select files and/or foldersfrom their computing device using the host computing file managementsystem as shown.

The patient may also add a note 230 (which would be visible to theSecure Fetch requestor and/or to another grantee that has been providedaccess to the uploaded digital content) should they choose to do sousing the provided note 230 window. An expiration timer 255 may be setby the patient to govern how long access to the subject files will beavailable to the Secure Fetch user. As an example, a patient may decideto make the files available for a day, a week, a month, or indefinitely.By selecting the calendar 255 menu, a second window 260 opens, allowingthe patient to select a date in which a shared file will no longer beavailable. An expiration time 270 may also be set by selecting the time270 window shown in FIG. 2. This selection will bring up an additionalwindow 275 which allows the patient to provision the exact time which ashare will expire. The window 275 shows a 24-hour clock. It is notedthat the clock can be displayed in any configuration, as can thecalendar 255 function. In addition, the system may be configured toallow the requestee to set a limited number of times the shared contentcan be accessed. For example, if the information to be shared isconsidered highly sensitive, the requestee might elect to only allow asingle viewing of the content before the share is disabled. As discussedabove, the system may be configured to allow the requestor, in thiscase, the hospital, to disable the requestee's ability to set anexpiration timer or to change the other options provided as examples inthis figure such as notes, encryption, and download control. As alsodiscussed, the requestor might also choose to set encryption, downloadcontrol, or expiration on its own. The system may be configured topresent these selections to the requestee in the user interface to makethe requestee aware of the security level that will be implemented withthe share. Note that it is contemplated that in some instances it may bedesirable for one or more grantees to have access to the contentprovided while the requestor does not. For example, a hospital staffmember could be instructed to set up the Secure Fetch and could act as arequestor while a doctor or insurance entity may be a grantee. In thisinstance, it may be beneficial for a requestor not to have access to thedigital content, which may be of a sensitive nature. As another example,in a legal context, a staff member at a law office may serve as arequestor to facilitate the sharing of sensitive information between anattorney or a client, or two attorneys, which parties can be identifiedas requestees and grantees as appropriate for the circumstances.

With continued reference to FIG. 2, a patient may also choose to preventor allow download 235 of a file, folder or other digital content sharedthrough Secure Fetch. As an example, a patient may choose to make adocument such as a driver license or passport shared through the systemas “view only.” By selecting the download 235 toggle, the patient mayprevent the download, causing the shared file to be visible to theSecure Fetch requestor, but not downloadable. This selection can bechanged by the patient at any time during the share duration asdetermined by the calendar 255 and timer 270 functions. As with theexpiration timer, the system may be configured to allow the requestor todisable the requestee's option of choosing whether the content can bedownloaded.

The patient can also choose to encrypt 240 files that are being sharedto the Secure Fetch requestor (the hospital). This will protect thefiles and folders while in transit and in storage at the Secure Fetchrequestor (hospital) location. The hospital itself will govern theencryption and be able to unlock any file encrypted through the use ofthe Secure Fetch. The encryption is intended to provide an added layerof protection for the patient during file transit and storage.

Once the patient has completed their file and folder sharing selectionsand affected all of the attributes of the share, they can then selectthe share 250 function to complete the transaction. Selecting cancel 245will cancel all settings and provisions enabled by the patient whichwould effectively terminate the Secure Fetch session. The session may bereopened by the patient by selecting the link 205 that was used toenable the Secure Fetch session. It is understood that the hospital canwithdraw or otherwise disable the link 205 to the Secure Fetch sessionat any time.

While this is one example, Secure Fetch may be configured withadditional options and features. For example, a requestor may actuallybe more than one user, thus allowing multiple users to act as requestorsand to set up a Secure Fetch. A requestor also may be permitted to senda Secure Fetch link 205 to multiple requestees at once. In the hospitalexample, the hospital may desire to send a Secure Fetch to both parentsof a minor child patient so that they can each upload documents. Inaddition, the requestor may desire that other parties in addition to, oreven instead of, the requestor shall have access to the materialprovided by the requestee(s). In the hospital example, the hospitalcould organize the Secure Fetch but it may be beneficial to make theuploaded documents available to other doctors or perhaps a healthinsurance entity. It may be, for example, that a requestor sends aSecure Fetch link 205 to three requestees, and also makes whatevermaterial that is provided by those requestees available to other parties(grantees), who, in this example, are also not required to have accountsor have downloaded the software for the file sharing and transfersystem. In a preferred embodiment, only the requestor that creates theSecure Fetch profile is required to have an account with the systemand/or to be running the application.

In another embodiment, the Secure Fetch functionality can be used withPINApp. For example, a requestee may “pin” a file to be provided insteadof transferring it. In this instance, access to the file would be viathe pinned file, and the file itself would not move. In such anembodiment, the requestor could select an option to either allow orrequire a requestee to pin a file. Other options, including thosepreviously mentioned, could also be included, such as whether therequestor or the requestee selects whether a party that is to haveaccess to the content (which could be the requestor or one or more othergrantees) can download it. In a preferred embodiment, the requesteewould not need to have a PINApp account or to have downloaded PINAppsoftware in order to pin a file. Instead, a requestor that set up theSecure Fetch could give access to PINApp functionality to the requesteethrough the requestor's PINApp account. It is important to note that,throughout this description, whenever a requestee populates a SecureFetch link 205, such as by providing their content via the same, it isassumed that the requestee could pin the material to facilitate sharingor transferring it. Thus, Secure Fetch can work both by actuallytransferring a copy of the digital content that is to be shared or bygranting access to that digital content while the digital content nevermoves from the requestee's device.

In another embodiment, the Secure Fetch functionality can be used withPINApp ARC. In this embodiment, an ARC profile (which may, in thiscontext, be called a Secure Fetch profile) may be created that does notcontain a file, folder or other digital content, but instead may be sentto a requestee to allow the requestee to add one or more files orfolders to a Secure Fetch profile to enable the content to be safelydelivered to the requestor that created the Secure Fetch profile (or toother grantees identified by the requestor).

The ARC system enables the creation of a digital access profile togovern the usage of digital content managed and/or protected by the ARC.The ARC works by taking the access and usage input and creating adigital access profile to govern how the subject digital content isutilized, accessed, stored, managed, forwarded and/or engaged by arecipient party(s).

A Secure Fetch profile utilizing ARC functions like an ARC profile. ASecure Fetch profile contains all elements of the digital content beingmanaged in addition to all the control parameters designated by theprofile creator. The ARC takes these elements and creates a single,easily transported digital content format (or profile) to carry the hostcontent and control information across devices, networks, domains, andbetween one or more parties. The ARC also contains encryption,expiration, display, and messaging information required to enable bothPINApp and non-PINApp requestees to access subject digital content.

Based on the parameters set, the ARC may allow digital content to bepassed between devices, networks, and domains, or may require arequestor or grantee to access the digital content directly from arequestee's host location within a host system (such as PINApp). Likeother embodiments discussed above, these parameters may be set by arequestor, or, if the requestor elects to provide a requestee withoptions, by a requestee. The ARC may be utilized to enable a requestorto take control and/or receive a digital copy of the requestee'soriginal content for the purpose of storing a back-up or creating a“spare.” The digital content may require enhanced security restrictions,wherein the requestor (or another grantee) may not take ownership of thedigital content, but rather be able to view the content in the hostlocation that the requestee has selected. By allowing the requestor thatcreated a profile, and, as allowed by that requestor, the requestee, tomaintain control of content that may be accessed by other parties, theARC aligns with regulations and controls such as HIPAA and otherregulations that govern the management of very personal and privatedigital content such as patient records, legal documents, and the like.

As an example of the use of Secure Fetch with ARC, a requestor maycreate a Secure Fetch profile and pass that profile to a requestee. Therequestee (not affiliated with the PINApp and/or ARC system) may thenadd one or more files or folders to the subject Secure Fetch profile,and return the Secure Fetch profile to the requestor. By enabling peoplenot affiliated with the subject systems to safely and securely transferfiles to participants of the system, the usability of the PINApp and ARCsystems are expanded, enabling simple access to parties that are bothaffiliated and not affiliated with the system.

As with any ARC profile created, access to the content in a Secure Fetchprofile is discretionary and dependent upon the needs of the creator ofthe profile (the requestor), or, if configured by that requestor, therequestee. Specifically, the requestor may designate him/herself ashaving access to the content in a Secure Fetch profile being populatedwith one or more files and folders by a non-affiliated party, or maydesignate a third-party grantee to be permitted to access the contentbeing supplied to the profile by the non-affiliated requestee.

As an example of the above, a requestor creates a Secure Fetch profileto be populated with files and/or folders provided by a requestee. Aswith the previous example, the requestee is not affiliated with thePINApp system and may not otherwise create an ARC or Secure Fetchprofile. The requestor may designate a grantee as the recipient of theSecure Fetch profile being populated with the subject files and/orfolders by the requestee. As the requestee populates and then sends thepopulated Secure Fetch profile, it will arrive at the grantee and maynot be redirected by the requestee or the grantee unless otherwiseprovisioned for by the requestor (creator of the Secure Fetch profile).This allows the provisioner/creator of the Secure Fetch profile todirect the content and manage it to ensure privacy, security andultimate control over the delivery of the subject content. This isparticularly important in instances wherein delicate and confidentialcontent such as medical/patient records are being managed throughhealthcare administrators or the like.

In another preferred embodiment, the Secure Fetch profile may bepopulated with files/folders or other content by multiple requesteesprior to being returned/sent to the requestor or other grantees selectedby the requestor (or the requestee) to receive access to the contentitself. As with the above examples, a Secure Fetch profile may becreated by a requestor with access and controls necessary for thecreation of the subject Secure Fetch profile. The Secure Fetch profilemay then be sent to multiple requestees to have content added, and thensent to one or more grantees selected by the requestor to receive accessto the subject content. This may be done utilizing a single Secure Fetchprofile, or multiple Secure Fetch profiles, depending entirely upon theconfiguration that the requestor generating the Secure Fetch profilechooses. Specifically, a single Secure Fetch profile may be created andsent to multiple requestees, enabling each of them to add content andforward the profile on until it reaches the grantees, or multiple SecureFetch profiles may be created and sent to each requestee separately tobe populated with the subject files, folders and digital content, andthen sent directly to the grantees. Again, this configuration isdetermined by the needs of the person(s) creating the Secure Fetchprofile.

Another example of the Secure Fetch will now be discussed with referenceto FIG. 3. It is important to note that while other embodiments exist,the discussion has been limited to highlight the preferred embodimentsand functional elements of the Secure Fetch function. FIG. 3 assumesthat the requestor creating the Secure Fetch (empty ARC profile) hasalready logged into their account and given access to the ARC functions.A requestee of the Secure Fetch who is intended to populate it withdigital content (files, folders or other) is not a user of the ARCsystem and does not have access to the functional elements containedtherein.

As a brief recap of the system components utilized to generate and sharea Secure Fetch (empty ARC profile), and with reference to FIG. 3, thetop section of the diagram illustrates the PINApp or host system 305engaging a processor 307 to facilitate operations between the PINApp orhost system 305 and the ARC operating system 310. The processor 307 isalso connected to a communication device 312 such as a wired or wirelessnetwork or other interface allowing external communications to externaldevices such as smart phones, computers, tablets or other computingdevices capable of communicating over a network. The lower section ofFIG. 3 illustrates the modules (A through J) that make up the SecureFetch profile 380. For the purpose of easing understanding of the SecureFetch profile creation, the modules (A through J) represent specificfunctional elements and attributes assigned to digital content beingadded to the Secure Fetch and subsequently being managed by the SecureFetch profile 380. The quantity of controls and restrictions in thisexample (with reference to FIG. 3) are limited to ease understanding ofthe creation of the Secure Fetch profile 380. It will become obvious toone skilled in the art that a virtually limitless set of control aspectsmay be attached to create a Secure Fetch profile. The example referencedin FIG. 3 is not intended to limit the scope of the Secure Fetch profile380, or the creation thereof.

Creation of the Secure Fetch profile 380 begins with a user of the ARCand PINApp host system, a requestor (not shown), logging into the host(PINApp 305) system, and subsequently the ARC operating system 310through the owner authentication node 315. The owner authentication node315 works in conjunction with the ARC database 330 as well as the hostsystem (PINApp 305) to ensure the identity of the requestor wishing toaccess the ARC. FIG. 3 assumes the identification information for therequestor in the PINApp or host system 305 database (not shown) matchesthe identification information stored in the ARC database 330, whichsubsequently allows the requestor (not shown) to access the ARC system.

Now that the identity of the requestor (not shown) is validated by theARC operating system 310 and the PINApp or host system 305, therequestor (not shown) can begin creating a Secure Fetch profile 380.Since the profile will be empty by default, no file selection will bemade at this time, as the files, folders and other digital content 395will be supplied by the requestee/content provider 313.

The requestor (not shown) will access the ARC instructions input UI 320and designate that the content will be populated by one or morerequestees/content providers 313. It is important to note that theSecure Fetch profile 380 may or may not specifically contain a copy ofthe digital content 395 that will be referenced. ARC provides thecapability of enabling the transport (through the Secure Fetch Profile)of one or more files and/or folders or other digital content, or may beconfigured to provide a physical location of the subject digitalcontent. This determination is made based on the needs of the usercreating the Secure Fetch profile, or if the requestor desires, by therequestee. As the requestee/content provider 313 populates the SecureFetch profile 380 with the subject digital content 395 (via a physicaladdress to the content or by providing the content itself), the ARCoperating system 310 will update the ARC database 330 about the locationand attributes of the digital content 395 being referenced by the SecureFetch profile 380.

Once the ARC database 330 has stored the file name, file size, file typeand has verified the physical location of the subject digital contentfile 395, it will notify the ARC location management node 335 to attachthe associated digital content data 365 to the new Secure Fetch profile380 being generated. Again, the digital content file 395 itself may bephysically added to the Secure Fetch 380 profile, or may be referencedthrough addressing schemes that provide the physical location of thedigital content 395 so that it may be retrieved.

The digital content data 365 being attached to the Secure Fetch profilemay be the file name, file type, file size and location data, allowingthe ARC to validate the location and establish a link between thedigital content itself (the video file) and the Secure Fetch profile, ormay be the physical digital content 395 itself. In instances where thelocation of the digital content 395 is being used, the ARC locationmanagement node 335 will continuously track the location of the digitalcontent file 395 and keep the ARC database 330 updated as to the currentlocation to ensure the integrity of all ARC profiles (including 380)associated with the subject digital content file 395, provided therequestor 313 has given permissions to do so.

The digital content data 365 (e.g., file name, file type, file size,etc.) is now added to a newly generated Secure Fetch profile 380 asrepresented by block-A 331. Now that the requestee/content provider 313has provided access to the digital content 395 the digital content 395will be governed by attributes selected by the requestor (not shown) whocreated the Secure Fetch profile 380. Again, please note that block-A331 now contains information relating to the digital content 395 that isnow being managed through the Secure Fetch profile 380. The requestor(not shown) who created the Secure Fetch profile 380 can identifygrantees that are to receive access to the subject digital content 395,now being managed by block-A 331 for inclusion in the Secure Fetchprofile 380.

For the purpose of this example with reference to FIG. 3, informationconcerning the identity of grantees that are to receive access to thedigital content hosted by the Secure Fetch profile and managed throughthe ARC will be configured based on the host system (PINApp 305) userdatabase information. In instances where the ARC is deployed as astand-alone management tool, the identification information of granteeswill be entered into the ARC system and stored in the ARC database 330.

With reference to FIG. 3, the ARC addressing node 340 manages theaddressing of the grantees to control access to the contents (digitalcontent data 365) managed within the Secure Fetch profile 380. Therequestor (not shown) will enter an identifier into the ARC instructionsinput UI 320 (in this example, an employee ID number) to indicate thegrantees who will be given access to the subject digital content file395 managed within the Secure Fetch profile 380. The ARC database 330will record the identifier information of the grantees for futureretention and to ensure the integrity of the Secure Fetch profile 380being created. The addressing information of the grantees will be storedwithin the newly created ARC profile 380 as block-C 341.

The next component for creation of the profile will be the display andrendering information (created by the ARC display management node 345)for the digital content file 395. Since the digital content file 395 isa video, the ARC display management node 345 will provide criteria suchas screen formatting, color composition, file playback formatting, andthe like. Engaging with the ARC instructions input UI 320, the requestornotes that the digital content file 395 is an MP4-type file.

While the ARC can manage a virtually unlimited number of digital contentformats, the MP4 designation is used to ease explanation of the creationof the Secure Fetch profile 380. As the MP4 designation is selected, theARC instructions input UI 320 shares this information with the ARCdatabase 330, which subsequently stores it with reference to the subjectSecure Fetch profile 380 being created. The ARC database 330 instructsthe ARC display management node 345 to provision the Secure Fetchprofile 380 to render and/or display the digital content file 395 (videofile) as an MP4 file. The ARC display management node 345 adds thedisplay and content formatting information (MP4) to the Secure Fetchprofile 380 being created. The MP4 and other display and renderinginformation created is stored as block-D 346 within the Secure Fetchprofile 380.

The next step in the creation of the Secure Fetch profile 380 (withcontinued reference to FIG. 3) is the expiration and/or usage durationof the digital content file 395, which is controlled by the ARCexpiration and duration node 350. To ease explanation and understandingof the functional aspects of the ARC, this discussion assumes thedigital content file 395 will be available to the grantees for anindefinite period of time, and an indefinite number of usages. The ARCis capable of allowing the requestor (or, if the requestor allows, therequestee) to put specific usage numbers and/or expiration dates andtimes on digital content being managed through the ARC.

In this example, the requestor creating the Secure Fetch profile 380(not shown), through the ARC instructions input UI 320 enters “neverexpire” as the expiration date and the number of uses at “infinite” forthe digital content file 395. The ARC instructions input UI 320 sharesthis command information with the ARC database 330. The ARC database 330stores the expiration and usage criteria for the Secure Fetch profile380 and instructs the ARC expiration and duration node 350 to set thedigital content file 395 to never expire, and to allow infinite uses.These usage and duration parameters are stored as block-E 351 of theSecure Fetch profile 380. Please note that the Secure Fetch profile 380data as individual blocks of data (blocks A through J) as well as thecompleted profile 380 itself are stored within the ARC database 330.

The next step in the creation of the Secure Fetch profile 380 is theoption to create a personalized message to accompany the digital contentfile 395 that can be managed and/or transferred to, for example, agrantee, through the ARC. The ARC notification and messaging node 355 isprovided to enable the creation of personalized messages as well as tomanage any communication between a requestor, requestee, and grantee, orto manage any ARC system level notifications that need to be shared witha requestor, requestee, or grantee. In addition to personal messagesfrom the requestor creating the Secure Fetch profile 380 to a requestee,which might include, for example, requests for specific digital content,messages that can be generated through the ARC notification andmessaging node 355 can include (but are not limited to) notifying arequestor and/or grantee when access to the digital content has beenenabled. Other messages that can be generated could notify the requestorand/or the requestee when the Secure Fetch profile is accessed by one ormore other parties that have been granted access to the digital contentstored in the Secure Fetch profile, or the number of times the digitalcontent file is accessed. Messages could also be generated related toany confirmation and/or error messages being communicated from the ARCoperating system 310 to the PINApp or host system 305, and the like.

For the purpose of this example (with continued reference to FIG. 3),the requestor (not shown) creating the Secure Fetch profile 380 couldinclude a message stating “here are Mr. Smith's medical records.” Therequestor (not shown) creating the Secure Fetch profile 380 will enterthe reference message into the ARC instructions input UI 320. Themessage will then be transferred to the ARC database 330 for storage.The ARC database 330 will engage the ARC notification and messaging node355, providing instructions to attach the subject message (“here are Mr.Smith's medical records”) to the digital content file 395. The messaginginformation provided from the ARC notification and messaging node 355 isthus associated to the digital content file 395 and can, if therequestor has selected, be shared to the grantees. The messaginginformation is then added to the Secure Fetch profile 380 as block-F356. As is the case with all Secure Fetch profile 380 information, theARC database 330 will host both the individual elements (blocks Athrough J) that make up the Secure Fetch profile 380, as well as thecompleted Secure Fetch profile 380.

The next step in the creation of the Secure Fetch profile 380 (withcontinued reference to FIG. 3) is the addition of encryption to protectthe digital content data 365 and the Secure Fetch profile 380. Throughthe ARC instructions input UI 320, the Secure Fetch profile 380 creator(not pictured) will select the appropriate encryption to protect thesubject Secure Fetch profile 380. Encryption methodologies may bedictated by the host system (PINApp 305) or may be dictated by the ARCoperating system 310, should the ARC be deployed as a stand-alonedigital content management tool.

For the purpose of this example, we will assume the requestor (notshown) creating the Secure Fetch profile 380 wishes to employ 2-factor(pin and token) authentication to the subject Secure Fetch profile 380.From the ARC instructions input UI 320, the digital content owner willselect 2-factor authentication. The selection is passed to the ARCdatabase 330 for storage. The ARC database 330 will then engage the ARCencryption node 360 and set the encryption parameters for the digitalcontent data 365 to 2-factor authentication. The 2-factor authenticationinformation is attached to the Secure Fetch profile 380 as block-G 361.

As with all control parameters added to the Secure Fetch profile 380,the ARC database 330 will store the completed Secure Fetch profile 380blocks-A through J for future retention, and to ensure the integrity ofeach Secure Fetch profile 380 being created. Block-H 366 represents theARC database 330 information for the subject Secure Fetch profile 380.The ARC database 330 information contained in Block-H 366 includes (butis not limited to) a summary of all blocks thus far (A through G) inaddition to the digital content owner identification information, asummary overview of the digital content file 395 being managed throughthe Secure Fetch profile 380, the requestee/content provider device 313physical addressing and MAC information, as well as a stamp providingthe date, time, device, operating system, and other information specificto the device wherein the Secure Fetch profile 380 was created. Theabove information, along with all previously disclosed blocks (A throughG) are summarized within the Secure Fetch profile 380 as block-H 366.

With continued reference to FIG. 3, the final step in the creation of aSecure Fetch profile 380 is the algorithm that encapsulates thereferenced blocks of data (blocks A through J) and renders the codinginto a format that can be easily managed through the host (PINApp 305)system as well as the grantee device(s) (not shown) that will be allowedaccess to the subject digital content file 395 managed by the SecureFetch profile 380. The encapsulation of the Secure Fetch profile 380 isrepresented by block-J 385 of FIG. 3.

The process of encapsulation (block-J 385) begins when the requestor(not shown) creating the Secure Fetch profile 380 has indicated throughthe ARC instructions input UI 320 that the creation of the Secure Fetchprofile 380 is completed. The ARC instructions input UI 320 notifies theARC operating system 310 of the completed Secure Fetch profile 380, andthe ARC operating system 310 begins the encapsulation process to createthe completed profile block-J 385. Once the encapsulation process hasbeen completed, the ARC operating system 310 notifies the ARC database330 that the creation of the subject ARC profile 380 has beensuccessfully completed. The ARC database 330 will store the completedSecure Fetch profile 380 as well as the encapsulation informationrepresented as block-J 385. The ARC database 330 will store all blockinformation (A through J) as separate components. Each encapsulationevent is created using a prediction resistant algorithm to ensure theintegrity of the Secure Fetch profile 380, and to ensure that hacking orotherwise breaching the Secure Fetch profile 380 to access the digitalcontent file 395 is discouraged. The encapsulation of the Secure Fetchprofile 380 (as represented by block-J 385) takes place with each newlycreated Secure Fetch profile, regardless of the encryption methodology(block-G 361) chosen to protect the Secure Fetch profile 380 duringtransit between devices, requestees, grantees, and/or networks.

As stated previously, all Secure Fetch profiles (including Secure Fetchprofile 380) are stored in the ARC database 330 for retention and accessthrough both the host system (PINApp or other host system 305) or canalso be accessed from the ARC database 330 via the ARC instructionsinput UI 320 at any time.

Completed Secure Fetch profiles can be stored within the host system asstated above, as well as being transferred to one or more requestees forthe purpose of allowing the one or more requestees to gain access to thedigital content being managed through the ARC.

What is claimed is:
 1. A system for obtaining digital content for one ormore requestors from one or more requestees comprising: one or morecommunication devices in communication with the one or more requestees;and one or more host systems that: receive a selection of one or morerequestees; present to the one or more requestees one or more userinterfaces that receive digital content; send to the selection of one ormore requestees one or more links to the one or more user interfaces;and receive the digital content from the selection of one or morerequestees via the one or more user interfaces and the one or morecommunication devices; wherein the one or more requestors areauthenticated by the one or more host systems while the selection of oneor more requestees are not authenticated.
 2. The system of claim 1,wherein the one or more host systems provide access to the digitalcontent to the one or more requestors.
 3. The system of claim 1, whereinthe one or more host systems receive a selection of one or moregrantees, wherein the one or more grantees have access to the digitalcontent via the one or more host systems.
 4. The system of claim 1,wherein the one or more host systems uniquely generate the one or moreuser interfaces for each of the selection of one or more requestees; 5.The system of claim 2, wherein the one or more host systems allow onlyviewing access to the digital content.
 6. The system of claim 1, whereinthe one or more host systems store the digital content in one or moreencrypted blocks on one or more storage devices.
 7. The system of claim3, wherein the access to the digital content provided to the one or moregrantees expires after a predefined period of time.
 8. A system forobtaining digital content for one or more requestors from one or morerequestees comprising: one or more storage devices; one or morecommunication devices in communication with the one or more requestees;one or more host systems that: present one or more user interfaces thatreceive digital data; send to the one or more requestees one or morelinks to the one or more user interfaces; receive the digital data fromthe one or more requestees via the one or more user interfaces and theone or more communication devices; and transmit the digital data to theone or more requestors upon request; wherein the digital data identifiesthe location of the digital content at one or more client devicesbelonging to each of the one or more requestees, the digital contentstored on the one or more client devices; and wherein the one or morerequestors are authenticated by the one or more host systems while theone or more requestees are not.
 9. The system of claim 8, wherein theone or more host systems receive a selection of one or more grantees,wherein the one or more grantees are not authenticated by the one ormore host systems and have access to the digital data and the digitalcontent.
 10. The system of claim 9, wherein the one or more grantees areprovided with access to the digital content from the one or more clientdevices without the digital content being stored on the one or more hostsystems and without the one or more requestors being provided withaccess to the digital content.
 11. The system of claim 8, wherein theone or more host systems uniquely generate the one or more userinterfaces for each of the plurality of requestees;
 12. The system ofclaim 8, wherein the one or more requestors are provided with access tothe digital content from the one or more client devices without thedigital content being stored on the one or more host systems.
 13. Thesystem of claim 12, wherein the access to the digital content providedto the one or more requestors expires after a predefined period of time.14. The system of claim 8, wherein the one or more requestors arenotified with a predefined message when the digital content is receivedfrom the one or more requestees.
 15. A computer-implemented method forobtaining digital content for one or more requestors from one or morerequestees, the method comprising: presenting one or more userinterfaces that receive digital content; sending to the plurality ofrequestees one or more links to the one or more user interfaces;receiving the digital content from the one or more requestees via theone or more user interfaces; storing the digital content on one or morestorage devices; and providing access to the digital content to the oneor more requestors upon request; wherein the one or more requestors areauthenticated by the one or more host systems while the one or morerequestees are not.
 16. The computer-implemented method of claim 15,further comprising receiving a selection of one or more grantees,wherein the one or more grantees are not authenticated by the one ormore host systems and have access to the digital content.
 17. Thecomputer-implemented method of claim 15, further comprising uniquelygenerating the one or more user interfaces for each of the one or morerequestees.
 18. The computer-implemented method of claim 15, whereinaccess to the digital content is provided for viewing only.
 19. Thecomputer-implemented method of claim 15, wherein the one or more linksexpire after a predefined period of time.
 20. The computer-implementedmethod of claim 15, wherein the digital content is stored in one or moreencrypted blocks on one or more storage devices.